前面幾天，我們已經讓 AI Agent 做了不少事情：讀取專案、修改程式、Debug、Code Review，甚至連 Git 的變更內容都能幫我們整理。

看到這裡可能會覺得，AI 好像已經什麼都能做了。

但其實 AI 本身能做的事情沒有想像中那麼多。

假設今天我對 AI 說：

幫我查看 GitHub 上這個專案目前有哪些 Issue，整理出還沒處理的 Bug。

問題就來了。

AI 就算知道 GitHub 是什麼，也不代表它天生就能直接進入 GitHub、讀取我們的 Repository，再把 Issue 抓回來。

如果想讓 AI 真的完成這類任務，就需要讓它有辦法使用外部的工具（Tools）。

從「會回答」變成「會使用工具」

可以把 AI 想成一個很聰明，但是原本只能待在房間裡的人。

我們問：

今天台中的天氣如何？

它可能知道很多跟天氣有關的知識，但如果沒有即時資料來源，就不一定知道「今天」到底幾度。

如果替它接上一個天氣服務，它就可以：

使用者
  ↓
AI
  ↓
天氣工具
  ↓
取得即時資料
  ↓
AI 整理結果
  ↓
回答使用者

Coding Agent 也是類似的概念。

前面使用 Claude Code、Gemini CLI 時，它們能夠讀取檔案、修改程式或執行 Terminal 指令，本質上就是因為 AI 不再只有「產生文字」這項能力，而是可以透過工具完成更多操作。

但新的問題又來了。

假設今天 AI 想連接 GitHub、Google Drive、資料庫、瀏覽器，甚至公司自己開發的內部系統，每一種服務都有自己的使用方式。

如果每個 AI 工具都要重新設計一次連接方法，事情就會變得非常麻煩。

這時候就輪到今天的主角——MCP。

MCP 到底是什麼？

MCP 的全名是 Model Context Protocol，可以把它理解成一套讓 AI 應用程式與外部工具、資料來源溝通的標準。

概念上可以想成：

AI / Coding Agent
        ↓
       MCP
        ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
GitHub  檔案   資料庫

以前不同服務可能需要各自想辦法串接；有了共同的協定後，AI 應用程式就可以用比較一致的方式去發現與使用這些能力。

所以 MCP 本身不是另一個 AI 模型，也不是像 Cursor 一樣的程式編輯器。

它比較像是 AI 與外部世界之間的一種「共同語言」。

這也是為什麼 MCP 會跟 Agent 經常一起出現。

Agent 負責思考：

「為了完成這個任務，我接下來需要做什麼？」

而 Tool 負責真的執行那些事情，MCP 則提供一種標準化方式，讓 AI 應用程式可以連接這些外部能力。

所以一路從前面的內容串過來，其實會變成：

Prompt
  ↓
告訴 AI 要做什麼

Context
  ↓
提供 AI 判斷需要的資訊

Agent
  ↓
自己規劃並執行任務

Tools / MCP
  ↓
讓 Agent 能接觸更多外部能力

到這裡先理解這個概念就夠了，不需要第一天看到 MCP 就開始研究 Protocol、JSON-RPC 或自己寫 Server。

明天 Day 22，我們就真的挑一個簡單的 MCP 來玩玩看，看看 Agent 接上工具之後，到底能多做些什麼。